1. Field of the Invention
The present invention relates generally to an improved data processing system for monitoring software performance, and in particular, to selective monitoring of individual transactions in an instrumented software application.
2. Description of the Related Art
Performance monitoring is often used in optimizing the use of software in a system. A performance monitor is generally regarded as a facility incorporated into a processor to assist in analyzing selected characteristics of a system by determining the state of a machine at a particular point in time. One method of monitoring system performance is to monitor the system using a transactional-based view. In this manner, the performance monitor may access the end user experience by tracking the execution path of a transaction to locate where problems occur. Thus, the experience of the end user is taken into account in determining if the system is providing the service needed.
A key task in system administration is to monitor the performance and availability of software applications, including those that may spread across multiple physical systems involving multiple physical resources. Typically, this monitoring is performed by instrumenting the software to include additional instructions, called “probes,” to report performance information, such as application response time. Performance monitoring may also be implemented in an enterprise by adding an additional software component, sometimes called a plug-in, to the application that is invoked in line during the execution of the transaction. Since the monitoring is performed in real time, any such monitoring causes some degree of run time performance overhead on the monitored systems. Thus, it is important to provide a control mechanism to configure the monitoring activity at an adequate granularity.
There are currently two main approaches for controlling performance overhead. The first approach includes selectively turning the monitoring on or off based upon the application or logic component. For example, when a user initiates a transaction from a Web browser, the request is sent to a Web server, which in turn makes a call to an application server and a database server. Traditionally, if the user has experienced a performance problem, the entire application that runs on the Web server, the application server, and the database server would be monitored in order to pinpoint the root cause of the problem. However, there are two major drawbacks to this application-based approach. When transaction monitoring is enabled for an application, all business transactions in that application will be monitored, regardless of whether or not they are relevant to identify the performance bottleneck. This all-inclusive monitoring incurs more overhead in terms of CPU usage, memory, etc., than necessary to solve the problem. In addition, when transaction monitoring is enabled for an application, every transaction in the application will generate additional monitoring information at the same level. The accumulated data volume can become very high within a short period of time, thus incurring additional overhead to process the data.
The second approach for controlling performance overhead is to have each business transaction associated with a “token” that embeds the entire monitoring configuration that should be used for the individual transaction. This approach is disclosed in U.S. patent application Ser. No. 10/971,472 now U.S. Pat. No. 7,552,212, titled “INTELLIGENT PERFORMANCE MONITORING BASED ON USER TRANSACTIONS”, and filed on Oct. 22, 2004. Each instrumented application has an entry point for requests (business transactions) to be monitored. Once these entry points are defined for the application, monitoring policies are associated with those entry points. The monitoring policy is represented as a token, which embeds all information necessary to monitor the transaction. However, a drawback to this approach is that there is no other control mechanism for deciding when the transaction should be monitored, other than a predefined sampling rate. This lack of control is problematic because anomalies in the system could occur during business transactions that are not being monitored.